Apparatus and method for integrated payment and electronic merchandise transfer

ABSTRACT

Payment transactions using a payment infrastructure are efficiently combined with e-merchandise transactions using an e-merchandise infrastructure, while allowing each infrastructure to concentrate on its primary function. An electronic payment device configured according to the payment infrastructure is interrogated by a payment module (also configured according to the payment infrastructure) of a first terminal to obtain financial data. Electronic merchandise-related information is generated by an electronic merchandise module (configured according to the electronic merchandise infrastructure) of the first terminal, and such information is transferred to the electronic payment device within a transaction conducted in accordance with the financial data and the payment infrastructure.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims the benefit of United States ProvisionalPatent Application Ser. No. 60/699,015 filed on Jul. 13, 2005, andentitled “Ticketing Extended Contactless Payment Device.” The disclosureof the aforementioned Provisional Patent Application Ser. No.60/699,015, including the complete appendix thereof, is expresslyincorporated herein by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates generally to the electronic and computerarts, and, more particularly, to apparatus and methods for electronicpayments and electronic merchandise transfer.

BACKGROUND OF THE INVENTION

Typically, payment transactions and delivery of electronic merchandise(also known as “e-merchandise”; the terms are used interchangeablyherein) are handled by separate infrastructures. For example, a paymenttransaction may be conducted using a payment card or other paymentdevice, together with an infrastructure that handles only the payment.Similarly, delivery of e-merchandise (for example, electronic tickets,tokens, digital credentials, movies, music, loyalty points, benefitcoupons, vouchers, data, a cryptographic key or “unlock” code, andsimilar non-physical items) is handled by a separate, perhapscomplimentary, infrastructure which may invoke the paymentinfrastructure in order to charge for the goods as a separate process.

Netherlands Patent Application No. NL9301902, published Jun. 1, 1995, ofNederland PTT, discloses a method for the acquisition of the right to aspecific facility by means of a smart card. The acquisition of the rightis performed via a terminal and a control system. The right to thefacility can be an access or a usage right. A smart card or otherregistration device is used to aid the access. The smart card is usednot only to pay for the required facility, but as a registration andvalidation means to replace paper tickets. Thus, the same smart card canbe used for the purchase of the right to a future facility, for thepayment thereof, and for the subsequent use of the facilities, that is,the exercise of the purchased right.

U.S. Pat. No. 6,375,084 of Stanford et al., issued Apr. 23, 2002,describes card charging systems. A host ticket facility is operable byboth credit cards usable at a card read/write device and concessionarypayment cards usable at a contactless card reader, and a security andtransaction device located between the card readers and the hostfacility stores in separate storage devices full fares and concessionaryfares which the host facility is able to calculate. A card chargingsystem is described, having one or more card readers and a security andtransaction device connected between the card readers and a hostfacility for transmitting information back to a clearing center. U.S.Pat. No. 6,402,038 of Stanford et al., issued Jun. 11, 2002, appears tobe similar to the Stanford et al. '084 reference just described.

U.S. Pat. No. 6,101,477 of Hohle et al., issued Aug. 8, 2000, disclosesmethods and apparatus for a travel-related multi-function smart card. Inone embodiment, the smart card system includes a card holderidentification application and various additional applications useful inparticular travel contexts, for example, airline, hotel, rental car andpayment-related applications. Memory space and security features withinspecific applications provide partnering organizations, such asairlines, hotel chains, and rental car agencies, the ability toconstruct custom and secure file structures.

U.S. Patent Publication No. 2006/049258 of Piikivi, published Mar. 9,2006, discloses a wireless communication device providing a contactlessinterface for a smart card reader. A wireless terminal including a smartcard application host, such as a contact smart card or the terminal or aterminal security component, and including a terminal interface, andalso including a smart card router that enables RF communication with acontactless card reader in a ticketing system is provided. The smartcard application host does not contain a contactless interface. Thesmart card router includes an RF antenna, separate from and external tothe smart card application host, as well as a modulator/demodulator anda card access module and router for routing communication trafficarriving via the RF antenna to either the smart card application host orto the terminal interface, based on information included in the arrivingcommunication traffic.

U.S. Patent Application Publication No. 2002/0147907 of Ross, publishedOct. 10, 2002, is directed to a system for authorizing transactionsusing specially formatted smart cards. The transaction system includesthe use of a fixed data structure that allows multiple point-of-salesystems to recognize and access a transaction card regardless ofupper-level user interfaces. The smart card includes a memory with adefined data file structure, and the data file structure includes atleast one read-only field, at least one encrypted read/write field, andat least one non-encrypted read/write field. The smart card can beutilized in a transaction system and the smart card authorization deviceinteracts with a defined data file structure provided on the smart card.

United States Patent Application Publication No. 2001/0018660 of Sehr,published Aug. 30, 2001, is directed to an electronic ticketing systemand methods utilizing multi-service visitor cards. A plurality ofentities are encompassed, such as an event organizer, admission center,service providers and a visitor population, so as to automaticallycompile, issue, utilize and process ticketing cards for the admission toleisure and entertainment events, and for other card-based entitlements.The portable ticketing cards are realized by smart credit and/or debitcard technology and have the ability to store in the card a computerizedticket template or electronic credit points, or to deduct from the carda monetary value or award points previously loaded onto the card.Biometrics identification of card holders, as well as cryptographiccertification of card data and database information, can optionally beencoded into the cards, and can be verified and validated at variouspoint-of-service locations upon presentation of the card for admissionand for other services.

Prior art techniques inefficiently employ separate and unlinked paymentand e-merchandise (e.g., ticketing) infrastructures and transactions.

It would be desirable to overcome the deficiencies of prior arttechniques.

SUMMARY OF THE INVENTION

Principles of the present invention provide techniques that permit theefficient combination of payment transactions using a paymentinfrastructure with e-merchandise transactions using an e-merchandiseinfrastructure, while allowing each infrastructure to concentrate on itsprimary function, typically without the necessity for detailedunderstanding and incorporation of the other infrastructure. Thus,provision of tickets or other e-merchandise can be linked to atransaction, such as a payment transaction. An exemplary embodiment of amethod (which can be computer-implemented) according to one aspect ofthe invention, includes the steps of facilitating interrogation of anelectronic payment device by a first terminal to obtain financial data,facilitating generation of e-merchandise related information, andfacilitating transfer of the e-merchandise related information. Theelectronic payment device can be interrogated by a first terminal, so asto obtain financial data and optionally profile data pertaining to aholder of the electronic payment device. The electronic payment devicecan be configured according to a payment infrastructure. The firstterminal can have a first terminal payment module configured accordingto the payment infrastructure and a first terminal electronicmerchandise module configured according to an electronic merchandiseinfrastructure and coupled to the first terminal payment module. Theinterrogation of the electronic payment device can be performed by thefirst terminal payment module.

The generation of the e-merchandise-related information can be done bythe first terminal electronic merchandise module, and the transfer ofthe e-merchandise related information to the electronic payment devicecan be done by the first terminal payment module. The transfer of thee-merchandise-related information is done within a transaction that isconducted in accordance with the financial data and the paymentinfrastructure. Where the optional profile data is obtained, thee-merchandise related information can be generated based on the profiledata.

In another aspect, an exemplary embodiment of a terminal for integratedpayment and electronic merchandise transfer can include a payment moduleand an electronic merchandise module that is coupled to the paymentmodule. The payment module can be configured according to the paymentinfrastructure and the electronic merchandise module can be configuredaccording to the electronic merchandise infrastructure. The modules canbe configured to facilitate the steps described above.

An exemplary embodiment of an electronic payment device (such as a cardor appropriately-configured cellular phone), according to another aspectof the invention, can include a memory and at least one processorcoupled to the memory. The processor can be operative to facilitateperformance of one or more of the method steps described herein. One ormore method steps of the present invention can be implemented in theform of an article of manufacture comprising a machine readable mediumthat contains one or more programs that when executed implement suchstep or steps.

One or more techniques of the present invention can provide one or moreof the following substantial beneficial technical effects. These caninclude, for example, allowing for the close coupling of separateinfrastructures, such as, for example, electronic payment and ticketing,while still respecting the separation of functions and responsibilitiesof each. Further, in another aspect, one or more inventive techniquesallow extending rather than replacing existing payment protocols, insuch a way that the extensions remain compatible with other parts of theexisting payment infrastructure. Yet further, in an exemplary embodimentconforming to the EMV payment standard as discussed more fully below, apayment card application can remain compliant with all relevant openstandards and the relevant type approval processes can remainapplicable.

Still further, in yet another aspect, by closely coupling payment anddata handling and/or storage functionality, the extension of open schemepayments, such as credit card payments, can be facilitated intoenvironments where traditionally only tickets or closed scheme payments,such as prepaid transport cards, have been accepted. Because payment anddata handling and/or storage can, if desired, be implemented in a singleapplication on a payment card, transaction time and complexity can begreatly reduced; in particular, as opposed to employing separate cardapplications for payment and data handling and/or storage, andespecially for high-speed contactless operations such as mass transitticketing and payment, transaction time can be substantially reduced ascompared to prior art techniques. Yet further, the complexity of thecard management process can be substantially reduced since only a singlecard application need be managed, and multiple electronic merchandiseapplications can be supported without change. Even further, complexityof terminals can be reduced, since ticketing and other e-merchandiseprocessing need not “understand” the payment side, and paymentprocessing need not “understand” e-merchandise functionality (i.e.,functionality of each side can remain substantially unmodified). In yetanother aspect, one or more inventive techniques can permit combinationof payment and electronic merchandise delivery in a single step, in sucha way that the payment transaction and the delivery of e-merchandise,such as a permit to travel, are closely bound, thus minimizing the riskof payment without delivery or of delivery without payment, and in sucha way that multiple payment for the same e-merchandise or unintendedmultiple delivery of merchandise for a single payment can typically beavoided.

These and other features and advantages of the invention will becomeapparent from the following detailed description of illustrativeembodiments thereof, which is to be read in connection with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example of a system and various components thereof thatcan implement techniques of the invention;

FIG. 2 shows one specific exemplary application of inventive techniquesto a controlled access system;

FIG. 3 is a flowchart of exemplary method steps according to an aspectof the invention;

FIG. 4 is a specific exemplary flowchart showing an exemplarytransaction flow at the entry of a system for payment at the entry tothe system;

FIG. 5 is a specific detailed flowchart showing exemplary method stepsin one specific exemplary transaction flow for storing an electronicticket at a reader;

FIG. 6 shows specific exemplary method steps for the transaction flow atthe exit to a controlled access system for payment at the exit;

FIG. 7 shows exemplary data flows for purchasing and storinge-merchandise, including exemplary security features;

FIG. 8 exemplary data flows for updating e-merchandise, includingexemplary security features;

FIG. 9 shows a traditional trust model;

FIG. 10 shows purchase within an exemplary inventive extended trustmodel;

FIG. 11 shows usage within the exemplary inventive extended trust model;and

FIG. 12 is a block diagram of an exemplary computer system useful in oneor more embodiments of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Attention should now be given to FIG. 1, which depicts an exemplaryembodiment of a system 100 together with various possible components ofthe system. System 100 can implement inventive techniques, and caninclude one or more different types of portable payment devices. Forexample, one such device can be a contact device such as card 102. Card102 can include an integrated circuit (IC) chip 104 having a processorportion 106 and a memory portion 108. A plurality of electrical contacts110 can be provided for communication purposes. In addition to orinstead of card 102, system 100 can also be designed to work with acontactless device such as card 112. Card 112 can include an IC chip 114having a processor portion 116 and a memory portion 118. An antenna 120can be provided for contactless communication, such as, for example,using radio frequency (RF) electromagnetic waves. An oscillator oroscillators, and/or additional appropriate circuitry for one or more ofmodulation, demodulation, downconversion, and the like can be provided.Note that cards 102, 112 are exemplary of a variety of devices that canbe employed with techniques of the present invention. In one or moreembodiments of the invention, a dual-interface device 1302 is employed.Device 1302 is shown larger than devices 102, 112 for illustrativeconvenience but can have a similar form factor. Device 1302 includes anIC chip 1304 having a processor portion 1306 and a memory portion 1308.A plurality of electrical contacts 1310, similar to contacts 110, can beprovided, as well as an antenna 1320 similar to antenna 120, togetherwith an oscillator or oscillators, and/or additional appropriatecircuitry for one or more of modulation, demodulation, downconversion,and the like, as described with regard to device 112. Appropriatefirmware to manage the two available interfaces can be provided, withoperation otherwise being similar to devices 102, 112. The descriptionof devices, elements or components 102, 104, 106, 108, 110, 112, 114,116, 118, 120 throughout this document are equally applicable to thecorresponding items 1302, 1304, 1306, 1308, 1310, 1320. Memories 108,118, 148 (discussed below) and 1308 may further be divided intonon-volatile and volatile memory.

The ICs 104, 114 can contain processing units 106, 116 and memory units108, 118. Preferably, the ICs 104, 114 can also include one or more ofcontrol logic, a timer, and input/output ports. Such elements are wellknown in the IC art and are not separately illustrated. One or both ofthe ICs 104, 114 can also include a co-processor, again, well-known andnot separately illustrated. The control logic can provide, inconjunction with processing units 106, 116, the control necessary tohandle communications between memory units 108, 118 and the input/outputports. The timer can provide a timing reference signal from processingunits 106, 116 and the control logic. The co-processor could provide theability to perform complex computations in real time, such as thoserequired by cryptographic algorithms.

The memory portions or units 108, 118 may include different types ofmemory, such as volatile and non-volatile memory and read-only andprogrammable memory. The memory units can store transaction card datasuch as, e.g., a user's primary account number (“PAN”). The memoryportions or units 108, 118 can store the operating system of the cards102, 112. The operating system loads and executes applications andprovides file management or other basic card services to theapplications. In some embodiments, one or more applications may “sit”directly on hardware, e.g., may be outside the domain of the operatingsystem. One operating system that can be used to implement the presentinvention is the MULTOS® operating system licensed by StepNexus Inc.Alternatively, JAVA CARD™-based operating systems, based on JAVA CARD™technology (licensed by Sun Microsystems, Inc., 4150 Network Circle,Santa Clara, Calif. 95054 USA), or proprietary operating systemsavailable from a number of vendors, could be employed. Preferably, theoperating system is stored in read-only memory (“ROM”) within memoryportion 108, 118. In an alternate embodiment, flash memory or othernon-volatile and/or volatile types of memory may also be used in thememory units 108, 118.

In addition to the basic services provided by the operating system,memory portions 108, 118 may also include one or more applications asdescribed herein. At present, one preferred standard to which suchapplications may conform is the EMV payment standard set forth by EMVCo,LLC (http://www.emvco.com). It will be appreciated that, strictlyspeaking, the EMV standard defines the behavior of a terminal; however,the card can be configured to conform with such EMV-compliant terminalbehavior and in such a sense is itself EMV-compliant. It will also beappreciated that applications in accordance with the present inventioncan be configured in a variety of different ways.

As noted, cards 102, 112 are examples of a variety of payment devicesthat can be employed with techniques of the present invention. Theprimary function of the payment devices may not be payment, for example,they may be cellular phone handsets, or access cards for a publictransportation system, that implement techniques of the presentinvention. Such devices could include cards having a conventional formfactor, smaller or larger cards, cards of different shape, key fobs,personal digital assistants (PDAs), appropriately configured cell phonehandsets, or indeed any device with the processing and memorycapabilities to implement techniques of the present invention. Thecards, or other payment devices, can include memories 108, 118 andprocessors 106, 116 coupled to the memories. Optionally, body portions(e.g., laminated plastic layers of a payment card, case or cabinet of aPDA, chip packaging, and the like) are associated with memories 108, 118and processors 106, 116. The memories 108, 118 can contain applicationsas described herein. The processors 106, 116 can be operative to executeone or more method steps to be described herein. The applications canbe, for example, application identifiers (AIDs) linked to software codein the form of firmware plus data in a card memory such as anelectrically erasable programmable read-only memory (EEPROM).

A number of different types of terminals can be employed with system100. Such terminals can include a contact terminal 122 configured tointerface with contact-type device 102, a wireless terminal 124configured to interface with wireless device 112, or a combined terminal126. Note that “contactless” and “wireless” are used in aninterchangeable fashion herein and that the skilled artisan is familiarwith the meaning of such terminology. Combined terminal 126 is designedto interface with either type of device 102, 112. Terminals may becontact terminals with plug-in contactless readers. Combined terminal126 can include a memory 128, a processor portion 130, and a readermodule 132. Note that the principles of construction of terminal 126 areapplicable to other types of terminals and are described in detail forillustrative purposes. Reader module 132 can be configured for contactcommunication with card or device 102, or contactless communication withcard or device 112, or both (different types of readers can be providedto interact with different types of cards e.g., contacted orcontactless). Terminals 122, 124, 126 can be connected to a processingcenter 140 via a computer network 138. Network 138 could include, forexample, the Internet, or a proprietary network. Processing center 140can include, for example, a host computer of an issuer of a paymentdevice. One or more distinct networks can be employed. As discussedbelow, inventive terminals can have payment modules coupled toelectronic merchandise modules; the modules can be implemented insoftware, firmware, and/or hardware. In one or more embodiments, themodules may be software modules running on the same processor.

Stand-alone terminal 134 is representative of a terminal that is notconnected to a computer network (either not connected at a particulartime, or not connected at all, by design), and is otherwise generallysimilar to the other terminals described.

An appropriately configured cellular telephone handset 142 can also beemployed in system 100. Handset 142 is depicted in semi-schematic formin FIG. 1, and can include one or more IC chips such as chip 144including a processing unit 146 and a memory unit 148. Wirelesscommunication with a terminal can be provided via antenna 150 or with asecond antenna 180 similar to above-described antenna 120 (i.e., thehandset could have a second antenna for the payment application). Notethat antenna 180 is depicted schematically, but could be, e.g., a coilantenna as used in a typical “smart” card. Handsets 142 can each beequipped with a suitable display 156. Further, an appropriate powersupply 162 can also be provided. Such power supplies can include, forexample, a battery and appropriate circuitry. The display and powersupply can be interconnected with the processor portion. Different typesof portable payment devices can combine or “mix and match” one or morefeatures depicted on the exemplary devices in FIG. 1.

In one aspect of the present invention, an electronic payment device,which may be portable, is provided for facilitating transactions by auser with a terminal, such as 122, 124, 126, 134, of a system such assystem 100. The device can include a processor, for example, theprocessing units 106, 116, 146 discussed above. The device can alsoinclude a memory, such as memory portions 108, 118, 148 discussed above,that is coupled to the processor. Further, the device can optionallyinclude a communications module that is coupled to the processor andconfigured to interface with a terminal such as one of the terminals122, 124, 126, 134. The communications module can include, for example,the contacts 110 or antennas 120, 150, 180 together with appropriatecircuitry (such as the aforementioned oscillator or oscillators andrelated circuitry) that permits interfacing with the terminals viacontact or wireless communication. The processor of the apparatus can beoperable to perform one or more steps of methods and techniquesdescribed herein. The processor can perform such operations via hardwaretechniques, and/or under the influence of program instructions stored inone of the memory units. The portable device can include a body portion.For example, this could be a laminated plastic body (as discussed above)in the case of “smart” cards 102, 112, or the handset chassis and bodyin the case of handset 142.

It will be appreciated that the terminals 122, 124, 126, 134 areexamples of terminal apparatuses for interacting with portable paymentdevices in accordance with one or more exemplary embodiments of thepresent invention. The apparatus can include the aforementioned paymentand electronic merchandise modules, implemented, e.g., via a processorsuch as processor 130, a memory such as memory 128 that is coupled tothe processor, and a communications module such as 132 that is coupledto the processor and configured to interface with the portableapparatuses 102, 112, 142. The processor 130 can be operable tocommunicate with portable payment devices of a user via thecommunications module 132. The terminal apparatuses can function viahardware techniques in processor 130, or by program instructions storedin memory 128. Such logic could optionally be provided from a centrallocation such as processing center 140 over network 138.

The above-described devices 102, 112 are preferably ISO 7816-compliantcontact cards or devices or NFC (Near Field Communications) or ISO14443-compliant proximity cards or devices. In operation, card 112 canbe touched or tapped on the terminal 124 or 128, which thencontactlessly transmits the electronic data to the proximity IC chip inthe card 112 or other wireless device.

FIG. 2 shows an exemplary application of techniques of the invention toa controlled access system, in accordance with one aspect of theinvention. The system 200 can be, for example, a transportation vehicle,a complete transportation infrastructure including one or more railroadstations or bus terminals, an amusement park, a museum, and the like.System 200 may have an entrance point 202 and an exit point 204. A firstterminal 206 can be located adjacent entrance point 202 and a secondterminal 208 can be located adjacent exit point 204. It will beappreciated that there may be multiple entry and exit points, and thateach may be provided with an appropriate terminal. The terminals, suchas terminal 206, can be configured for integrated payment and electronicmerchandise transfer via a payment infrastructure, in associated with anelectronic merchandise infrastructure, and in conjunction with anelectronic payment device, such as device 210, that is configuredaccording to the payment infrastructure. The device 210 can be, forexample, a contacted card, a contactless card, a cell phone, or otherdevice as described above.

Terminal 206 can include a payment module 212 that is configuredaccording to the payment infrastructure and that is also configured tointerrogate the electronic payment device 210 to obtain financial data.Further, terminal 206 can include an electronic merchandise module 214that is configured according to the electronic merchandiseinfrastructure and coupled to the payment module 212. The electronicmerchandise module 214 can be configured to facilitate processing ofe-merchandise related information, for example, ticketing information.The payment module 212 can be further configured to facilitate transferof the e-merchandise related information to the electronic paymentdevice 210, in a transaction conducted in accordance with the financialdata and the payment infrastructure. Note that the payment module caninclude an antenna 216 for contactless communication (appropriatemodulation and conversion circuitry, well known in the art and similarto that discussed above, can also be included). Further, the paymentmodule can include a reader for contacted cards, 218. Note that thereader 218 and antenna 216 can be separate entities or can be integratedwith the terminal 206 (e.g., payment module 212 thereof) as desired.Payment module 212 and electronic merchandise module 214 can havenetwork connections 220, 222. It will be appreciated that if desired, asingle network connection could be provided. The connection can be toany type of network described above with regard to FIG. 1, and thedifferent modules can be connected to the same or different networks asdesired. Elements 224, 226, 228, 230, 232, 236 of terminal 208 canfunction similarly to corresponding elements 212, 214, 216, 218, 220,222 of terminal 206.

In one or more embodiments, payment module 212 need not itself beconnected to a network and network communication can be accomplished viamerchandise module 214. Further, in one or more embodiments,communication with the card or other payment device is handled bypayment module 212, and any data that needs to be passed between thecard and the merchandise module 214 is handled by the payment module 212(for both contacted and contactless cards).

By way of an example to aid understanding of the skilled artisan, oneexample of a payment infrastructure is the EMV infrastructure, i.e. apayments system incorporating EMV, such as that operated by MasterCardInternational Inc. in conjunction with Issuers, Acquirers, andMerchants. Further, one example of an electronic merchandiseinfrastructure is an Automatic Fare Collection (AFC) system.

Optionally, payment module 212 can be further configured to interrogatethe electronic payment device 210 to obtain profile data pertaining to aholder of the electronic payment device. In this case, the electronicmerchandise module 214 of the first terminal 206 can be configured toprocess the e-merchandise related information based on the profile data.The processing of the e-merchandise related information can includegenerating, reading, and/or updating the e-merchandise relatedinformation. It will be appreciated that different types ofe-merchandise modules 214 are possible. For example, there may be somewhich only generate e-merchandise, such as ticket vending machines,there may be some which only read e-merchandise, for example, a portabledevice of a train conductor or other ticket inspector; and there may bethose which only update e-merchandise, for example, a ticket validationmachine. Further, there may be combined modules which do some or all ofthe foregoing in any combination. It is to be emphasized that by way ofexample, many aspects of the invention are illustrated with regard to aticketing system, for example, for transportation. However, this ispurely exemplary, and techniques of the present invention can beemployed in many applications, wherever integration of payment ande-merchandise infrastructures will be beneficial, such as, e.g.,controlling access to amusement parts, museums and the like.

Modules 212, 214, 224, 226 as described can include, e.g., twophysically separate devices, a single device comprising two discretesub-devices, a single device comprising two discrete virtual devices(i.e. software modules) and a single fully integrated device doing bothjobs.

Attention should now be given to FIG. 3, which presents a flowchart 300of exemplary method steps according to an aspect of the invention. Themethod, which can be computer-implemented, can be employed forintegrated payment and electronic merchandise transfer via a paymentinfrastructure in association with an electronic merchandiseinfrastructure. The e-merchandise can be of the kind described above.After beginning at block 302, block 304 includes facilitatinginterrogation of an electronic payment device by a first terminal toobtain financial data. The financial data can be, for example, anaccount number of the electronic payment device. The electronic paymentdevice can be configured according to the payment infrastructure, andthe first terminal can have a payment module and an electronicmerchandise module as described above with regard to FIG. 2. Theinterrogation of the electronic payment device can be performed by thefirst terminal payment module. Optionally, in the step of facilitatinginterrogation 304, profile data pertaining to a holder of the electronicpayment device can be obtained. As used herein, “facilitating” an actionincludes performing the action, making the action easier, helping tocarry the action out, or causing the action to be performed. Thus, byway of example and not limitation, instructions executing on oneprocessor might facilitate an action carried out by instructionsexecuting on a remote processor, by sending appropriate data or commandsto cause or aid the action to be performed.

As noted, the financial data can be, for example, an account numberassociated with the payment device. By way of example and notlimitation, the profile data could include information such as the factthat the person is a student or a senior citizen who is entitled to alower fare. Further, two or more categories of profile data could beprovided. For example, one category could include ticketing profiledata, such as senior citizen or student status. Further, card memberprofile data could also be provided; such data might not be needed forthe transaction. This could include, for example, when and where thecard member joined, personal information such as the size of clothing,and the like. Where the profile data is obtained, the e-merchandiserelated information can be generated by the first terminal electronicmerchandise module based on the profile data.

Optional step 306 will be discussed below. Step 308 can includefacilitating generation of e-merchandise related information by thefirst terminal electronic merchandise module. Such information couldinclude, for example, ticketing information. Optional steps 310 through316 will be discussed below. Step 318 can include facilitating transferof e-merchandise related information to the electronic payment device,via the first terminal payment module, within a transaction conducted inaccordance with the financial data and the payment infrastructure. Inone or more embodiments, the transaction may be a payment transaction.It should be appreciated, however, that the transaction may be for zerovalue, and/or might only be a subset of a full payment transaction flow.

As noted, the profile data that can optionally be obtained in step 304can include information identifying the holder of the electronic paymentdevice as a member of a class having one or more of a plurality ofentitlement categories that are associated with the class membership.The entitlement categories can relate to the electronic merchandise; forexample, such categories could include entitlements to discounts orprivileges. As noted, on one exemplary embodiment, the entitlementcategories may include transportation fare categories, and thee-merchandise related information may include transportation ticketinformation.

As noted, techniques of the invention may be used to control entrance toand/or exit from a controlled access system. In some cases, one may onlybe concerned with entrance to the system. This may be appropriate, forexample, when a single fixed fee is charged for access, such as entranceto a museum or amusement, or in mass transportation systems, such as theNew York subway system, where a single fare is charged for passagebetween any two stations. However, in other applications, it may bedesirable to also control exit, and/or to link the ticket or costinformation to both the entrance and exit points. This could correspond,for example, to a system such as the London Underground or WashingtonD.C. Metro. Thus, the steps described could be executed in connectionwith entrance of the holder to a controlled access system, and in suchcase, the e-merchandise related information in steps 308 and 318 couldinclude the initial entry point information. Thus, the fist terminal,such as terminal 206 in FIG. 2, can in this case be thought of as anentrance terminal. In this case, additional steps can include step 320,namely, facilitating interrogation of the electronic payment device byan exit terminal upon exit of the holder from the system, to obtainsystem entry point information (the exit terminal in essence already“knows” its own location, i.e., the system exit location). The exitterminal could be, for example, terminal 208 of FIG. 2. Step 322 caninclude facilitating one or more of providing a ticket to the holder andcharging a fee to the holder, via the exit terminal payment module,based upon the controlled access system entry point information andcontrolled access system exit point information (e.g., location of theexit terminal). It will be appreciated that the ticket provided in step322 (or elsewhere herein) could be an electronic ticket, a physicalticket, an optical ticket, and the like.

In one or more embodiments, the entrance and exit terminals 206, 208 maybe different. For example, in a transportation system, such as a subway,metro or underground system, the first, or entrance terminal 206 couldbe located at a station where a person boarded a train, while the secondor exit terminal 208 could be located at a station where a person exiteda train. However, it is possible that the entrance and exit terminalsmay in fact be the same terminal. This could occur, for example, on abus, where fares depended on how far one traveled. The exit terminal,which would be the same as the entrance terminal, could obtaininformation about how far one traveled by, for example, globalpositioning system (GPS) or other suitable techniques. The electronicpayment device employed with the method depicted in FIG. 3 can be, forexample, a contactless radio frequency (RF) proximity card, a contactedcard, or a dual-interface card having both contactless radio frequency(RF) and contacted interfaces. Furthermore, the device could have anon-card form factor such as, for example, a cellular telephone, a PDA,a key fob, and the like; all that is required is that the appropriatecapabilities be present to interface with the terminal.

It will be appreciated that in one or more exemplary embodiments, it maybe desirable to provide appropriate security features, to minimize thechance of fraud or improper usage. Specific examples will now beprovided within the context of a ticketing application. When an opendata store is used for a ticket, the card or other device may notprovide any security services to the ticketing application with regardto data storage. In this case, the ticketing application will need toaddress attacks such as skimming (i.e. copying a ticket to another card)or replay. However, in other embodiments, the card or other device couldprovide appropriate security support. One way would be to employ atransaction counter, such as the application transaction counter (ATC)in the PutData operation, in conjunction with the PutData command, toprevent the attacks. Note that the example is provided within thecontext of the aforementioned EMV specification. The skilled artisan,with the teachings presented in this application in hand, will be ableto readily adapt the example to other types of systems and standards.

More specifically, the reader (or reader portion of a terminal) couldask for the ATC and the primary account number (PAN). The ticketingmodule could include the ATC and PAN in the message authentication code(MAC) that it calculates, and could pass this back to the card or otherdevice using the PutData command. The PutData command would refuse toaccept the storage of the data, unless the PAN and ATC matched itscurrent values. This would stop replay onto a legitimate card by thecard holder. Further, use of the PAN in conjunction with the combineddata authentication (CDA) feature present in EMV could reduce oreliminate the chances of “skimming,” i.e., where someone attempts toread valid ticket data from another card and copy it onto their owncard. As the MAC includes the PAN and the PAN is signed by CDA, thepayment module can detect that fraudulent attempt and refuse thetransaction.

With reference to FIG. 3, where it is desired to implement securitytechniques, optional step 306 can include facilitating the interrogationof the electronic payment device, by the first terminal, to obtain atransaction counter and an account number, such as, for example, theaforementioned ATC and PAN. Step 310 can include facilitatingcalculation of an authentication code using the transaction counter andthe account number; the code can be, for example, the MAC. Step 312 caninclude facilitating the determination whether the transaction counterand the account number obtained from the electronic payment device matchthe transaction counter and the account number included in theauthentication code. If they do not, as indicated by the NO branch ofblock 312, refusal of storage of the authentication code by theelectronic payment device can be facilitated, as shown at block 316.Such refusal is responsive to the determining step revealing that thetransaction counter and the account number obtained from the electronicpayment device do not match those included in the authentication code.Implementing these steps can reduce the likelihood of a replay fraud. Ifthe match is acceptable, as indicated by the YES branch of block 312,optionally, skimming detection can be facilitated at decision block 314,based on the account number and a unique data authentication signatureassociated with the transaction, for example, the EMV signature methodknown as Combined DDA/AC Generation, more commonly referred to as “CDA”.Thus, chances of replay (attempting to copy previously legitimateticketing data back onto the original card) and skimming (attempts tocopy legitimate ticketing data onto another authentic or fraudulentcard) can be substantially reduced or eliminated. It will be appreciatedthat the replay and skimming prevention steps can be performed in anyorder, and need not be performed together; either or both can beperformed, or neither. Indeed, in general, the steps depicted in FIG. 3can be performed in any appropriate order, and not all the steps need becarried out in any particular situation. Once a refusal has beengenerated in block 316, processing proceeds to continue block 324.

In another approach exemplary of many possible approaches to securityenhancement, steps can include facilitating interrogation of anelectronic payment device by a first terminal to obtain a transactioncounter such as an ATC, an electronic payment device identifier such asCard ID, and an electronic payment device-generated random number suchas RND, and facilitating calculation of an authentication code such asMAC based on the e-merchandise related information, the transactioncounter, the electronic payment device identifier, and the electronicpayment device-generated random number. These steps permit facilitatingdetection of replay fraud via the transaction counter and the paymentdevice-generated random number, as well as facilitating skimmingdetection, based on linkage of the e-merchandise related information tothe electronic payment device identifier. Further details will beprovided below with regard to FIGS. 7 and 8.

By way of review, one or more embodiments of the invention can providetechniques for combining payment and e-merchandise infrastructuresand/or transactions while allowing each to concentrate on its primaryfunction, and with little or no need for one to understand orincorporate the other. Thus, in one or more aspects, the invention canprovide techniques for incorporating data handling operations into atransaction, such as a payment transaction. In one particular exemplaryimplementation, the payment transaction employs the aforementioned EMVstandard.

Thus, techniques of the present invention permit the processing ofnon-payment data within a transaction, such as a payment transaction. Inone or more exemplary embodiments, data handling can be conducted withinsuch a transaction. As discussed with regard to FIG. 2, terminals caninclude e-merchandise and payment modules; these can be implemented asseparate hardware modules or separate software modules. In one or moreembodiments, two separate applications are provided, one fore-merchandise such as ticketing, and one for payments. The device, suchas a card, only needs to “know” how to interface with the paymentportion. The e-merchandise data, such as ticketing, can be conveyed tothe card or other device through the payment application or other typeof payment module. Appropriate ticketing or other e-merchandise data canbe stored on the card or other device, but using the paymentinfrastructure preexisting on the card. In one or more embodiments, theexisting payment infrastructure can be in accordance with theaforementioned EMV specification. Standard EMV commands can be used tomove non-payment data, such as e-merchandise data. However, the card orother payment device can be made downward-compatible, so that it can bereadily employed for ordinary purchase transactions. Further specificexamples showing application of techniques of the invention within theEMV framework will now be presented with respect to FIGS. 4-6.

In the following discussion of FIGS. 4-8, “reader” encompasses anelement such as payment module 212 with elements 216 and/or 218, while“terminal” encompasses an element such as e-merchandise module 214. FIG.4 shows exemplary method steps in a transaction flow at the entry to acontrolled access system, where payment is to be made at the entry. Thesteps are described in the context of the aforementioned EMV standard,with appropriate modifications implementing techniques of the invention.The techniques are applicable to both contactless and contactedapplications. As shown in step 402 of flowchart 400, an activationrequest can be sent from a ticketing application to a paymentapplication. An appropriate card polling and activation sequence can beconducted at step 404. If an invalid card or multiple cards are present,as determined at step 406, a card deactivation sequence can be run atstep 408, and a “NAK” symbol can be sent from the reader to the terminalat block 410 (corresponding to the reader informing the terminal thatsomething has gone wrong).

Only in the case when a single card is present, the reader willimplement the application selection, and an appropriate application onthe card is selected at block 412. Data is then read from the card, asat block 414. Such data can include profile information such as aticketing profile, as well as a balance. When multiple cards arepresent, as in the NO branch, the reader will initiate a removalsequence, as at 408.

In step 416, the appropriate application is initiated. In step 418, thereader can read all the data from the card or other device, but mayretrieve only the PAN from the response message, saving other data forlater use. In the example shown in FIG. 4, the application data iscompliant with the ONESMART PAYPASS® application, also known as PAYPASSM/CHIP®, promulgated by MasterCard International Incorporated. However,this is purely for purposes of example, and other appropriatespecifications can be compiled with or employed. In parallel, at step420, the reader can send the ticketing profile and balance as part of anactivate entry response, as a result of two successful GetData commands.At step 422, the reader can receive a debit entry command and parseddata from the terminal as a preparation for a first Generate AC commandto be conducted in the future. In parallel, in step 418, appropriatedata is read from the card or other device by a Read Record command.Typically, in an optimized flow, the terminal will send the Debit Entrycommand before the reader reaches the point where it is ready to sendthe first Generate AC command. In block 424, the reader requests atransaction certificate (TC). In block 426, the reader sends the DebitEntry response to the terminal, containing the clearing record.

In block 428, a determination is made whether the card or other devicehas generated an application authentication cryptogram (AAC) or anauthorization request cryptogram (ARQC). If such is the case, the readerdeclines the transaction without further processing as shown at block410. Conversely, following the “no” branch at block 428, a determinationis made whether combined DDA/AC generation was requested. Note that“DDA” stands for Dynamic Data Authentication, “AC” stands forApplication Cryptogram, and the two are combined into “CDA” which standsfor “Combined DDA/AC.” If such generation was requested, at block 434,the reader retrieves the public key of the electronic payment device(such as, e.g., an Integrated Circuit Card (ICC) and verifies the signeddynamic application data (SDAD). At block 436, if the SDAD is correct,processing flows to block 438, while if the SDAD is incorrect, thereader declines the transaction as per block 410. In the “no” branch ofblock 430, static data authentication is performed at block 432 by thereader. The reader will set an appropriate bit in the TVR if the staticdata authentication fails. Note that “TVR” stands for TerminalVerification Results, a set of flags generated by the terminal thatcontains the results of the terminal's risk management decisions. Itpasses this to the card in “genAC.” In blocks 438 and 440 the readerperforms appropriate processing restrictions and terminal riskmanagement. Again, appropriate bits in the TVR are set if one or moretests fail.

In block 442, the reader performs terminal action analysis. If theresult is a TC request, as determined in block 444, the reader acceptsthe transaction; conversely, at the “no” branch of block 444, thetransaction is declined as at block 410. In block 448, the reader sendsthe Debit Entry response to the terminal, containing the clearingrecord. The reader can send the Debit Entry response to the terminalcontaining the output from the first Generate AC response; suitableexception handling may be implemented by the reader in the case that thecard or the other device does not respond to the Generate AC command. Itwill be appreciated that blocks 406, 418, 424, 428, 430-436, 438, 440,442 and 446 can correspond to actions taken at an application level.Further, blocks 402, 410, 420, 422, and 448 can correspond to actionstaken at a transport or e-merchandise level. The steps in FIG. 4 may becarried out in connection with terminal-reader interactions.

In general terms, in a normal EMV transaction flow, the rightapplication is selected on the card or other device, data is read fromthe card or other device, terminal risk analysis and terminal actionanalysis are performed, the card is asked for a cryptogram of a typedetermined by the above analysis, and the card then does its riskanalysis and responds to the terminal in an appropriate fashion. In themodified transaction flow set forth herein, when reading data from thecard, ticketing or e-merchandise related data may optionally also beread and supplied to the ticketing or other e-merchandise terminal. Suchdata can be read by the normal EMV Read Record command, or by one ormore GetData commands. When the card or other device is asked for acryptogram, the card is told certain data items in a format requested bythe card. The card request will typically include the ticket tag so thatif a ticket is present, it is passed to the card when the cryptogram isrequested (if ticketing is not understood, zeroes are simply passed tothe card). The card logs the data in an extension to the normaltransaction log. Optionally, it is also possible to write to a datastore before or after the cryptogram request. This can be done with aPutData command, but in a variation to normal EMV, it can be donewithout any securing acting just as an open data store. Both optionshave been discussed above. Optionally, if one is jut logging entry intoan area, the PutData need not be followed by a cryptogram request.

When the appropriate application is selected, the terminal can perform aGetProcessingOptions command. This command tells the terminal some basicfacts about the card and transaction and also provides a parameter whichis used to determine which Terminal File Records need to be read (in oneor more embodiments, such parameter can be, for example, the ApplicationFile Locator or “AFL” parameter from the EMV specification). This latterrecord is a list of the data items to be read for a given transaction.Records can then be read using the Read Record command. Other data itemssuch as the offline balance can be read with a GetData command.

Normally, PutData commands are done as part of “scripting,” i.e., asequence of cryptographically secured commands with MACs. In one or morecard applications configured in accordance with techniques of theinvention, both this type of PutData and a type of PutData that does nothave a MAC can be supported. A number of data stores used for storingtickets can be defined. Half of these can be open and half can be secure(i.e. freely read, scripting for write). Again, these details areexemplary in nature and other variations are possible.

One of the data items read in the Terminal File Records is called(CDOL1. This data item tells the terminal the list of tags to besupplied in the cryptogram request, items such as amount, currency, andthe like. To this can be added an extra tag for tickets or othere-merchandise, so that the terminal provides a ticket or othere-merchandise in the cryptogram request. The basic rule under the EMVstandard is that if a tag is not understood, zeroes are filled in. Thisfeature can be employed to ensure that a non-ticketing ornon-e-merchandise terminal will not reject a card or other deviceemploying inventive techniques.

The cryptogram can be requested by means of a “Generate AC” command.This cryptogram is typically only understood by the issuer, but the cardor other device may digitally sign it using RSA. RSA is a well-knownalgorithm for public key encryption that can also be used for digitalsignatures. The terminal can check this as it obtains the keys that itneeds from the terminal file records.

Attention should now be given to FIG. 5, which depicts an exemplaryreader transaction flow for the storage of a ticket or othere-merchandise. At block 502, the reader receives a GET CARD ID commandand begins polling for cards in the field (in the case of contactlesscards), as at block 504. At block 506, if a single card is present inthe field, the reader moves the application selection at block 512. Ifmultiple cards are present, the reader initiates the removal sequence asat block 508 and block 510. At block 516, the reader reads the firstrecord from the Terminal File Records. This record contains the PAN, theapplication expiry date, and optionally the PAN sequence number. Whilethe arrangement described may offer speed advantages, the PAN can, ifdesired, be located in any other record. The variables mentionedthroughout are familiar to the skilled artisan from the EMVspecification. At block 518, the reader parses record one, and retrievesthe PAN, application expiry date, and PAN sequence number. If the PANsequence number is not included in the record, the reader uses the value“00”.

At block 520, the reader sends the PAN, PAN sequence number and theapplication expiry data as the GetCard ID response. At block 522, thereader receives a store ticket command and parses the data as apreparation for the PutData command. The PutData command, for the ticketor other e-merchandise, is shown in block 524. The reader sends theticket or other e-merchandise to the card with the PutData command(without using secure messaging). At block 526, the card deactivationsequence occurs, while at block 528 the reader informs the terminal thateverything proceeded appropriately. Block 510 “Send NAK” corresponds tothe reader informing the terminal that something has gone wrong.

It will be appreciated that blocks 506, 516, 518 and 524 can correspondto activity at the application level. Blocks 504 and 526 can correspondto activity at the transport level. Blocks 502, 510, 520, 522, and 528can correspond to terminal-reader interactions.

FIG. 6 shows a flowchart 600 of exemplary method steps in a transactionflow at the exit from a controlled system, such as a transportationsystem, for payment at the exit. At block 602, the reader receives theACTIVATE EXIT command and begins polling for cards in the field, as atblock 604. If no ACTIVATE EXIT command has been received, monitoringcontinues, as indicated at the “no” branch of block 602. The cardpolling and activation sequence is depicted at block 604. At block 606,a determination is made whether a single card is present in the field;if so, the reader moves the application selection as at block 612.Conversely, if multiple cards are present, the reader initiates theremoval sequence, as at block 608, and the “Send NAK” block 610 isperformed; the reader sends a debit response to the terminal, containingthe status bytes from the first generate AC response as describedfurther herein. After application selection at block 612, a ticket,ticketing profile and balance can be read at block 614, and theappropriate application is initiated at block 616. In block 618, thereader reads record one of SFI 2 to retrieve the PAN, PAN sequencenumber and application expiry date. At block 624, the reader reads otherrecords to retrieve all required application data. In parallel, as shownat block 620, the reader sends the ticket, ticketing profile, balance,PAN, PAN sequence number and application expiry data as part of theACTIVATE EXIT response. Meanwhile, the reader is reading the other carddata, as at block 624 via Read Record commands.

At block 622, the reader receives the Debit Exit command and parses thedata as a preparation for a future first Generate AC command. Again, inparallel, as at block 624 the reader keeps reading card data via readrecord commands. Typically, the terminal has sent the Debit Exit commandbefore the reader is to send the first Generate AC command. The dataparsed in block 622 can include an amount and a transaction date and/ortime stamp. In block 626, the reader sends the PutData command to removethe ticket from the card, while in block 628, the reader requests atransaction certificate. The card deactivation sequence occurs in block630. In block 632, it is determined whether the card generated an AAC orARQC; if such is the case, as at the “yes” branch, the reader declinesthe transaction without further processing. If such is not the case, asat the “no” branch, a determination is made in block 634 whethercombined DDA/AC generation was requested. If this is the case, thereader retrieves the ICC public key and verifies the signed dynamicapplication data at block 636. If the signed dynamic application data isincorrect as determined at block 638, the transaction is declined, whileif the SDAD is correct, processing continues at block 642. If thedecision in block 634 is negative, static data authentication isperformed by the reader at block 640. The reader will set theappropriate bit in the TVR if the static data authentication fails. Inblocks 642 and 644 the reader performs processing restrictions andterminal risk management, setting the appropriate bits in the TVR if oneor more tests fail. The reader performs terminal action analysis inblock 646. If the result is a TC request, as determined in block 648,then the reader accepts the transaction, as per the “yes” branch. In thecase of a “no” answer, the transaction is declined. In block 650, forthe clearing record, the reader should use the TVR as sent to the card,not the TVR used to collect the terminal risk management results. Inblock 652, the reader sends the debit exit response to the terminal,containing the clearing record.

It will be appreciated that the method depicted in FIG. 6 is amodification of a standard EMV procedure, adding, for example, steps 620and 622. It will be further appreciated that blocks 606, 614, 618, 624,626, 628, 632, 634-638, 640, 642, 644, 646 and 650 can correspond toactions at the application level. Further, blocks 604, 608 and 630 cancorrespond to actions at the transport level. Finally, blocks 602, 610,620, 622, and 652 can correspond to terminal-reader interactions.

FIG. 7 shows how the e-merchandise is written to the payment device(referred to as a “Card”) as part of a payment transaction. With regardto FIGS. 7 and 8, the skilled artisan will appreciate from the contextthe significance of the variables and will also appreciate thatdifferent variable names could be chosen. The Terminal, Reader and Cardgo through the following steps. In step 701, the Terminal generates arandom number UN*. The Terminal calculates a challenge H* from therandom number UN* using a one-way-function (OWF). At this stage, onlythe Terminal knows UN* and it is difficult to calculate UN* if H* isknown. At 702, the Terminal sends an ACTIVATE command to the Reader toinitiate the application. The Terminal includes the tags of the dataelements that the reader should return in the ACTIVATE response message.This includes, e.g., the RND tag, ATC tag, Card ID tag and CustomerProfile tag. The Terminal also includes H* indicating to the Reader thatthe interaction with the Card must be completed with the COMMIT command.

In step 703, the Reader starts polling for a Card. If a Card is found,the Reader activate the Card. In step 704, the Reader selects theappropriate application and initiates the application. In step 705, theReader sends H* to the Card and receives RND and ATC. The card storesRND and H* in volatile memory for later use during the DEBIT and COMMITcommand. The presence of H* indicates to the Card that non-volatilememory must be updated with the COMMIT command. The Reader retrieves theCustomer Profile and Card ID from the Card in step 706.

In step 707, the Reader sends the data objects requested in step 702 tothe Terminal in the ACTIVATE response message. This includes the RND,ATC, Card ID and Customer Profile. The Terminal determines the Amountbased on the Customer Profile, at step 708; and calculates a MAC overthe data of the Merchandise, RND, ATC and Card ID, at step 709. This waythe Merchandise is linked to the Card ID and therefore it can not beused in another (genuine) Card. As it also includes the RND and ATC, itcannot be replayed to the same Card either. The Terminal stores theMerchandise in the MERCHANDISE envelope and fills the RND and ATC withhexadecimal 'F's. In step 710, the Terminal generates the Receipt.

At step 711, the Terminal sends the MERCHANDISE envelope together withthe payment related data and the Receipt to the Reader as part of theDEBITWRITE command. At step 712, the Reader sends the MERCHANDISEenvelope together with the payment related data and the Receipt to theCard as part of the DEBIT command. At step 713, the Card performs itscard risk management and generates a Proof of Payment. The Card keepsany updates, including the Merchandise and Receipt, in volatile memoryuntil UN* is presented as part of the COMMIT command. At step 714, theReader sends UN* to the Card as part of the COMMIT command. Upon receiptof the COMMIT command, in block 715, the Card verifies if H* received aspart of the GET CHALLENGE* is the same as OWF (UN*). If this is thecase, then the Card updates its non-volatile memory. It stores theMerchandise together with RND and ATC in the Merchandise container andstores the Receipt in the Receipt container. The Card also updates thepayment related parameters in non-volatile memory.

In block 716, the Reader authenticates the Card. The card authenticationassures the Reader that the Card linked to the Card ID is a genuineCard. The Reader passes the Proof of Payment to the Terminal in block717.

FIG. 8 shows how the e-merchandise is read, checked for integrity andauthenticity and then replaced by an update of the Merchandise. If theoriginal Merchandise is a multiple-ticket package, such as a LondonUnderground Carnet, the updated Merchandise will contain one Ticketless. If the original Merchandise is a single Ticket, the updateinvalidates the Ticket. The Terminal goes through the following steps.At step 801, the Terminal sends the ACTIVATE command to the Reader toinitiate the application. The Terminal includes the tags of the dataelements that the Reader must return in the ACTIVATE response message.The Terminal does not send H* to the Reader. This indicates to theReader that the transaction does not have to be completed with theCOMMIT command.

At block 802, the Reader starts polling for a Card. If a Card is found,the Reader activates the Card. In step 803, the Reader selects theappropriate application and initiates the application. In step 804, theReader sends the GET CHALLENGE* command and receives RND and ATC. TheCard stores RND in volatile memory for later use during the DEBITcommand. The Card does not receive H* from the Reader. This indicates tothe Card that no COMMIT command will be sent and that non-volatilememory must be updated with the DEBIT command.

In step 805, the Reader retrieves the Merchandise envelope currentlystored in the Card. The MERCHANDISE envelope contains Merchandise′, RND′and ATC′. In step 806, the Reader retrieves the Card ID from the Card.In step 807, the Reader sends the Card ID, RND, ATC and the MERCHANDISEenvelope to the Terminal in the ACTIVATE Rsp message. In block 808, theTerminal checks whether Merchandise′ was calculated over the RND′ andATC′ for the particular Card ID. If so, in block 809, the Terminalcalculates the new Merchandise over the same Card ID but uses the newRND and ATC. The Terminal stores the Merchandise in the MERCHANDISEenvelope and fills the RND and ATC with hexadecimal ‘F's. In block 810,the Terminal generates a Receipt.

In step 811, the Terminal sends the new MERCHANDISE envelope togetherwith the Receipt to the Reader as part of the DEBITWRITE command. TheDEBITWRITE command can be for a zero Amount so that there is nofinancial impact on the Card. In step 812, the Reader sends the newMERCHANDISE envelope together with the Receipt to the Card as part ofthe DEBIT command. In block 813, the Card stores the Merchandisetogether with RND and ATC in the Merchandise container and stores theReceipt in the Receipt container.

In steps 814, 815 and 816, the Reader authenticates the Card (the cardauthentication assures the Reader that the Card linked to the Card ID isa genuine card) and the Reader passes the Proof of Payment (for a zeroAmount) to the Terminal.

It will be appreciated that in general, prior art systems rely onmerchandise to be delivered after payment. One or more inventivetechniques enable a trust model of data storage that allows merchandiseto be delivered before payment occurs. Within this data storage concept,the availability of the merchandise is free but the usage(“consumption”) is restricted. Unlike physical goods, it doesn't costanything to “manufacture” bits & bytes. One can take the risk ofproviding e-merchandise as long as one is sure that payment is receivedbefore the e-goods are consumed. Therefore, the trust model of datastorage is believed to be particularly pertinent to e-merchandise. Themerchant can use this trust model if, e.g., he can rely on additionalcard functionality (such as trust in the issuer); the card applicationshould provide protection against cloning as well as against re-use ofgoods. Thus, the integration of payment with on-card data storage (e.g.ticketing or other e-merchandise) enables the new trust model, and oneor more inventive techniques can implement on-card data storage using afast and simple transaction flow.

To review, in the traditional trust model for card payment, the merchanttrusts the acquirer for payment. The merchant provides the client withgoods after a simple “OK” from the acquirer. The merchant knows theacquirer will honor this “OK” and pay the merchant as part of thesettlement process. In the extended model, the merchant also relies onadditional functionality in terminal and card to control distributionand usage of e-merchandise. Hence, the merchant needs to trust both theacquirer and the issuer for management of goods.

FIG. 9 illustrates the traditional trust model. In this model, there isa clean separation of responsibilities:

-   The merchant is responsible for the vending machine 902.-   The acquirer is responsible for the (payment) terminal 904.

Merchant and acquirer have a (commercial) relation based on trust: ifthe acquirer (via the terminal) confirms to the merchant (i.e. to thevending machine) that a transaction is successful, then goods 908 aredelivered. The acquirer shields the complexity of the card interactionfrom the merchant; there is no direct relation between merchant andissuer of the card 906.

The extended trust model applies when the goods are in electronicformat. In this case, the e-merchandise gives access to a service(transport, music, and the like), further referred to as “usage”. Atypical case is a client buying a ticket (e-merchandise) at a vendingmachine and then putting the ticket into a turnstile to open the gate(usage). If it concerns an e-ticket, a data carrier is needed to holdthe data. One choice for such a data carrier is the payment card usedfor buying the ticket. As the card is the carrier of the ticket, thecard will be involved at time of usage. This extra involvement of thecard requires an extension of the trust model to include both acquirerand issuer. FIG. 10 illustrates the proposed trust model for buying ane-ticket at the vending machine; FIG. 11 illustrates the proposed trustmodel at the gate.

Unlike FIG. 9, the vending machine 1002 in FIG. 10 provides the goods(e-merchandise) 1008 to the terminal 1004 prior to confirmation ofpayment. This requires an additional level of trust from the merchant.The merchant relies on the acquirer to implement a transaction flow thatprevents access to goods without payment. This additional level of trustfrom the merchant is acceptable as it concerns e-merchandise (binarydata). The e-merchandise has no value other than the service it givesaccess to. In case of non-payment, the merchant bears no financial lossas long as a client cannot use the goods. The issuer of the card 1006 isdepicted as in FIG. 9. p As seen in FIG. 11, when the client exchangesthe e-goods 1108 for services such as rail transport 1112, the gate 1110“talks” directly to the card 1106. As there is no payment to settle,acquirer and terminal are out of the loop. The merchant relies onadditional card functionality as protection against counterfeit goods.Hence, there must be a relation of trust between the merchant and theissuer.

Counterfeit goods include:

-   1. data created by a fraudster that is similar to or the same as    genuine goods-   2. clones of genuine goods-   3. replays of genuine goods.    Merchants already have ways of detecting fake goods in the gate.    They rely on the card functionality to protect against cloning and    replay. Therefore, within the extended trust model, the merchant    relies on the issuer to control usage of e-merchandise and to    provide countermeasures against cloning and replay.

In summary, in order for the extended trust model to work, the datastorage should protect against:

-   1. usage of unpaid goods (extended responsibility of acquirer)-   2. cloning of goods (extended responsibility of issuer)-   3. re-use of goods (extended responsibility of issuer)    Protection against fake goods remains the responsibility of the    merchant.

The relevance of having generic data storage functionality on card andterminal will now be described within the context of the extended trustmodel. In one or more inventive embodiments, protection mechanisms asjust described can be implemented

-   via a generic (payment) terminal-   via a generic (payment) card-   without requiring merchant controlled keys in either card or    terminal.

The usage of generic devices allows:

-   Issuers to provide payment cards that    -   Can be used for ticketing, loyalty, and the like    -   Without a pre-arrangement between the issuer and the merchant    -   Without knowledge of the specific requirements of the merchant.-   Acquirers to provide terminals that    -   Can be used for ticketing, loyalty, and the like    -   Without knowledge of the specific requirements of the merchant.-   Merchants to use generic payment cards and terminals    -   As vehicle for their specific data storage application    -   Without knowledge of the payment application.

More detail will now be given on the functionality provided by thegeneric data storage. In order to have the full benefit, the datastorage function in the card (and terminal) should allow for allmerchant specific requirements. In one or more embodiments, theenvisaged functionality covers may be as set forth in the followingtable:

Functionality Meaning 1. Retrieval of Client profiles containinformation about the client different client from the perspective ofthe merchant. The merchant profiles can use the client profile forgiving access to particular services determining the transaction amountAs the client profile is merchant specific, a single client may havedifferent profiles for different merchants in the same card. 2.Management of A single ticket provides a one-time access to a service.single tickets, After usage, the merchant invalidates the ticket so thatbooklets a client cannot use it again. (“carnets”) as A booklet is acollection of single tickets. Hence, a well as booklet is a particulartype of goods that is used subscriptions. gradually (e.g. one ticket atthe time). A subscription gives access to a service over a longer time.The validity of the subscription is defined by the merchant (a day, aweek, a month, and so on). 3. Management of A receipt is proof given tothe client when goods are receipts. exchange for services. It allows acustomer to proof that he/she is entitled to use the service (e.g. beingpresent on a train). Note: for subscriptions, receipts may not benecessary.

The invention can employ hardware and/or software aspects. Softwareincludes but is not limited to firmware, resident software, microcode,etc Software might be employed, for example, in connection with aterminal 122, 124, 126, 134, 206, 208. Firmware might be employed, forexample, in connection with payment devices such as cards 102, 112,1302. FIG. 12 is a block diagram of a system 1200 that can implementpart or all of one or more aspects or processes of the presentinvention. As shown in FIG. 12, memory 1230 configures the processor1220 (which could correspond, e.g., to processor portions 106, 116) toimplement one or more aspects of the methods, steps, and functionsdisclosed herein (collectively, shown as process 1280 in FIG. 12). Thememory 1230 could be distributed or local and the processor 1220 couldbe distributed or singular. The memory 1230 could be implemented as anelectrical, magnetic or optical memory, or any combination of these orother types of storage devices (including memory portions as describedabove with respect to cards 102, 112) It should be noted that ifdistributed processors are employed, each distributed processor thatmakes up processor 1220 generally contains its own addressable memoryspace. It should also be noted that some or all of computer system 1200can be incorporated into an application-specific or general-useintegrated circuit. For example, one or more method steps could beimplemented in hardware in an ASIC rather than using firmware. Display1240 is representative of a variety of possible input/output devices.

System and Article of Manufacture Details

As is shown in the art, part or all of one or more aspects of themethods and apparatus discussed herein may be distributed as an articleof manufacture that itself comprises a computer readable medium havingcomputer readable code means embodied thereon. The computer readableprogram code means is operable, in conjunction with a computer system,to carry out all or some of the steps to perform the methods or createthe apparatuses discussed herein. The computer readable medium may be arecordable medium (e.g., floppy disks, hard drives, compact disks,EEPROMs, or memory cards) or may be a transmission medium (e.g., anetwork comprising fiber-optics, the world-wide web, cables, or awireless channel using time-division multiple access, code-divisionmultiple access, or other radio-frequency channel). Any medium known ordeveloped that can store information suitable for use with a computersystem may be used. The computer-readable code means is any mechanismfor allowing a computer to read instructions and data, such as magneticvariations on a magnetic media or height variations on the surface of acompact disk.

The computer systems and servers described herein each contain a memorythat will configure associated processors to implement the methods,steps, and functions disclosed herein. Such methods, steps, andfunctions can be carried out, e.g., by processing capability on elements102, 112, 142, 122, 124, 126, 134, 140, 206, 208, or by any combinationof the foregoing. The memories could be distributed or local and theprocessors could be distributed or singular. The memories could beimplemented as an electrical, magnetic or optical memory, or anycombination of these or other types of storage devices. Moreover, theterm “memory” should be construed broadly enough to encompass anyinformation able to be read from or written to an address in theaddressable space accessed by an associated processor. With thisdefinition, information on a network is still within a memory becausethe associated processor can retrieve the information from the network.

Thus, elements of one or more embodiments of the present invention, suchas, for example, the aforementioned terminals 122, 124, 126, 134, 206,208 or payment devices such as cards 102, 112, 1302 can make use ofcomputer technology with appropriate instructions to implement methodsteps described herein. By way of further example, a terminal apparatus122, 124, 126, 134, 206, 208 could include a communications module, anantenna coupled to the communications module, a memory, and at least oneprocessor coupled to the memory and the communications module andoperative to interrogate a contactless payment device (in lieu of theantenna and communications module, appropriate contacts and otherelements could be provided to interrogate a contact payment device suchas a contact card).

Accordingly, it will be appreciated that one or more embodiments of thepresent invention can include a computer program comprising computerprogram code means adapted to perform one or all of the steps of anymethods or claims set forth herein when such program is run on acomputer, and that such program may be embodied on a computer readablemedium. Further, one or more embodiments of the present invention caninclude a computer comprising code adapted to cause the computer tocarry out one or more steps of methods or claims set forth herein,together with one or more apparatus elements or features as depicted anddescribed herein.

Although illustrative embodiments of the present invention have beendescribed herein with reference to the accompanying drawings, it is tobe understood that the invention is not limited to those preciseembodiments, and that various other changes and modifications may bemade by one skilled in the art without departing from the scope orspirit of the invention.

1. A computer-implemented method for integrated payment and electronicmerchandise transfer via: (i) a payment infrastructure, configured inaccordance with a payment system standard, in association with (ii) anelectronic merchandise infrastructure, comprising the steps of:facilitating interrogation of an electronic payment device by a firstterminal to obtain an account number associated with said electronicpayment device, said electronic payment device being configuredaccording to the payment system standard, said first terminal having afirst terminal payment module configured according to the payment systemstandard and a first terminal electronic merchandise module configuredaccording to the electronic merchandise infrastructure and coupled tosaid first terminal payment module to permit transfer of non-paymente-merchandise related information from said first terminal electronicmerchandise module to said first terminal payment module, saidinterrogation of said electronic payment device being performed by saidfirst terminal payment module; facilitating generation of saidnon-payment e-merchandise related information by said first terminalelectronic merchandise module; and facilitating transfer of saidnon-payment e-merchandise related information from said first terminalelectronic merchandise module to said electronic payment device via saidfirst terminal payment module, within a transaction between saidelectronic payment device and said first terminal payment module that isconducted in accordance with said account number and said payment systemstandard, said non-payment e-merchandise related information beingstored on said electronic payment device in accordance with said paymentsystem standard.
 2. The method of claim 1, wherein in said step offacilitating interrogation: profile data pertaining to a holder of saidelectronic payment device is obtained; and said e-merchandise relatedinformation is generated by said first terminal electronic merchandisemodule based on said profile data.
 3. The method of claim 2, whereinsaid profile data includes information identifying said holder of saidelectronic payment device as a member of a class having at least one ofa plurality of entitlement categories associated therewith, saidentitlement categories relating to said e-merchandise.
 4. The method ofclaim 3, wherein said entitlement categories comprise transportationfare categories and said e-merchandise related information comprisestransportation ticket information.
 5. The method of claim 1, whereinsaid steps are executed in connection with entrance of a holder to acontrolled access system and said e-merchandise related informationcomprises initial entry point information.
 6. The method of claim 5,wherein said first terminal is an entrance terminal, further comprisingthe additional steps of: facilitating interrogation of said electronicpayment device by an exit terminal upon exit of said holder from saidsystem, to obtain said initial entry point information, said exitterminal having an exit terminal payment module configured according tothe payment system standard and an exit terminal electronic merchandisemodule configured according to the electronic merchandise infrastructureand coupled to said exit terminal payment module to permit transfer ofnon-payment e-merchandise related information from said exit terminalelectronic merchandise module to said exit terminal payment module; andfacilitating at least one of: providing a ticket to the holder, andcharging a fee to the holder, via said exit terminal payment module,based upon said initial entry point information and a location of saidexit terminal.
 7. The method of claim 6, wherein said entrance terminaland said exit terminal are the same.
 8. The method of claim 6, whereinsaid entrance terminal and said exit terminal are distinct.
 9. Themethod of claim 6, wherein in said step of facilitating interrogation,profile data pertaining to a holder of said electronic payment device isobtained, said profile data including information identifying saidholder of said electronic payment device as a member of a class havingat least one of a plurality of entitlement categories associatedtherewith, said entitlement categories relating to said e-merchandise.10. The method of claim 9, wherein said entitlement categories comprisetransportation fare categories and said e-merchandise relatedinformation comprises transportation ticket information.
 11. The methodof claim 1, wherein said electronic payment device is a contactlessradio frequency (RF) proximity card.
 12. The method of claim 1, whereinsaid electronic payment device is a contacted card.
 13. The method ofclaim 1, wherein said electronic payment device is a dual-interface cardhaving both contactless radio frequency (RF) and contacted interfaces.14. The method of claim 1, wherein said electronic payment device has anon-card form factor.
 15. The method of claim 1, further comprising theadditional steps of: facilitating interrogation of said electronicpayment device by said first terminal to obtain a transaction counterand an account number; facilitating calculation of an authenticationcode including said transaction counter and said account number;facilitating determining whether said transaction counter and saidaccount number obtained from said electronic payment device match saidtransaction counter and said account number included in saidauthentication code; and facilitating refusal of storage of saidauthentication code by said electronic payment device, responsive tosaid determining revealing that said transaction counter and saidaccount number obtained from said electronic payment device do not matchsaid transaction counter and said account number included in saidauthentication code, whereby a likelihood of replay fraud is reduced;wherein said steps of facilitating interrogation, calculation,determining, and refusal are carried out substantially without keysharing with said electronic payment device.
 16. The method of claim 15,further comprising the additional step of: facilitating skimmingdetection, based on said account number, said authentication code, and aunique data authentication signature associated with said transaction,said authentication code including said account number, said accountnumber being signed by said unique data authentication signature. 17.The method of claim 1, further comprising the additional steps of:facilitating interrogation of said electronic payment device by saidfirst terminal to obtain a transaction counter, an electronic paymentdevice identifier, and an electronic payment device-generated randomnumber. facilitating calculation of an authentication code based on saide-merchandise related information, said transaction counter, saidelectronic payment device identifier, and said electronic paymentdevice-generated random number; facilitating detection of replay fraudvia said transaction counter and said payment device-generated randomnumber; wherein said steps of facilitating interrogation, calculation,and detection are carried out substantially without key sharing withsaid electronic payment device.
 18. The method of claim 17, furthercomprising the additional step of: facilitating skimming detection,based on linkage of said e-merchandise related information to saidelectronic payment device identifier.
 19. The method of claim 1, furthercomprising the additional step of facilitating payment for saide-merchandise, said payment occurring after said transfer of saide-merchandise related information to said electronic payment device. 20.The method of claim 19, further comprising the additional step offacilitating fraud detection substantially contemporaneously with anattempted usage of said e-merchandise related information.
 21. Themethod of claim 19, further comprising the additional step of preventingusage of said e-merchandise related information prior to said payment.22. A terminal for integrated payment and electronic merchandisetransfer via: (i) a payment infrastructure, configured in accordancewith a payment system standard, in association with (ii) an electronicmerchandise infrastructure and in conjunction with an electronic paymentdevice configured according to the payment system standard, saidterminal comprising: a payment module configured according to thepayment system standard and configured to interrogate the electronicpayment device to obtain an account number associated with saidelectronic payment device; and an electronic merchandise moduleconfigured according to the electronic merchandise infrastructure andcoupled to said payment module to permit transfer of non-paymente-merchandise related information from said electronic merchandisemodule to said payment module, said electronic merchandise module beingconfigured to facilitate processing of said non-payment e-merchandiserelated information; wherein said payment module is further configuredto facilitate transfer of said non-payment e-merchandise relatedinformation to the electronic payment device, in a transaction betweenthe electronic payment device and said payment module that is conductedin accordance with said account number and said payment system standard,said non-payment related e-merchandise related information being storedon said electronic payment device in accordance with said payment systemstandard.
 23. The terminal of claim 22, wherein: said payment module isfurther configured to interrogate the electronic payment device toobtain profile data pertaining to a holder of said electronic paymentdevice; and said first terminal electronic merchandise module isconfigured to process said e-merchandise related information based onsaid profile data.
 24. The terminal of claim 22, wherein said processingof said e-merchandise related information comprises generating saide-merchandise related information.
 25. The terminal of claim 22, whereinsaid processing of said e-merchandise related information comprisesreading said e-merchandise related information.
 26. The terminal ofclaim 22, wherein said processing of said e-merchandise relatedinformation comprises updating said e-merchandise related information.27. A computer program product comprising a computer usable mediumincluding computer usable program code for integrated payment andelectronic merchandise transfer via: (i) a payment infrastructure,configured in accordance with a payment system standard, in associationwith (ii) an electronic merchandise infrastructure, said computerprogram product including: computer usable program code for facilitatinginterrogation of an electronic payment device by a first terminal toobtain an account number associated with said electronic payment device,said electronic payment device being configured according to the paymentsystem standard, said first terminal having a first terminal paymentmodule configured according to the payment system standard and a firstterminal electronic merchandise module configured according to theelectronic merchandise infrastructure and coupled to said first terminalpayment module to permit transfer of non-payment e-merchandise relatedinformation from said first terminal electronic merchandise module tosaid first terminal payment module, said interrogation of saidelectronic payment device being performed by said first terminal paymentmodule; computer usable program code for facilitating generation ofnon-payment e-merchandise related information by said first terminalelectronic merchandise module; and computer usable program code forfacilitating transfer of said non-payment e-merchandise relatedinformation from said first terminal electronic merchandise module tosaid electronic payment device via said first terminal payment module,within a transaction between said electronic payment device and saidfirst terminal payment module that is conducted in accordance with saidaccount number and said payment system standard, said non-paymente-merchandise related information being stored on said electronicpayment device in accordance with said payment system standard.
 28. Thecomputer program product of claim 27, further comprising computer usableprogram code for obtaining profile data pertaining to a holder of saidelectronic payment device, wherein said e-merchandise relatedinformation is generated by said first terminal electronic merchandisemodule based on said profile data.
 29. The computer program product ofclaim 28, wherein said profile data includes information identifyingsaid holder of said electronic payment device as a member of a classhaving at least one of a plurality of entitlement categories associatedtherewith, said entitlement categories relating to said e-merchandise.30. An electronic payment device for facilitating integrated payment andelectronic merchandise transfer via: (i) a payment infrastructure,configured in accordance with a payment system standard in associationwith (ii) an electronic merchandise infrastructure, said electronicpayment device being configured according to the payment systemstandard, said electronic payment device comprising: a memory; and atleast one processor coupled to said memory, said processor beingoperative to: facilitate interrogation of said electronic payment deviceby a first terminal to obtain an account number associated with saidelectronic payment device, said first terminal having a first terminalpayment module configured according to the payment system standard and afirst terminal electronic merchandise module configured according to theelectronic merchandise infrastructure and coupled to said first terminalpayment module to permit transfer of non-payment e-merchandise relatedinformation from said first terminal electronic merchandise module tosaid first terminal payment module, said interrogation of saidelectronic payment device being performed by said first terminal paymentmodule; facilitate generation of said non-payment e-merchandise relatedinformation by said first terminal electronic merchandise module; andfacilitate transfer of said non-payment e-merchandise relatedinformation from said first terminal electronic merchandise module tosaid electronic payment device via said first terminal payment module,within a transaction between said electronic payment device and saidfirst terminal payment module that is conducted in accordance with saidaccount number and said payment system standard, said non-paymente-merchandise related information being stored on said electronicpayment device in accordance with said payment system standard.
 31. Theelectronic payment device of claim 30, wherein said processor is furtheroperative to facilitate said terminal obtaining profile data pertainingto a holder of said electronic payment device, wherein saide-merchandise related information is generated by said first terminalelectronic merchandise module based on said profile data.
 32. Theelectronic payment device of claim 31, wherein said profile dataincludes information identifying said holder of said electronic paymentdevice as a member of a class having at least one of a plurality ofentitlement categories associated therewith, said entitlement categoriesrelating to said e-merchandise.
 33. The electronic payment device ofclaim 30, wherein said processor is operative to perform said steps inconnection with entrance of a holder to a controlled access system andsaid e-merchandise related information comprises initial entry pointinformation.
 34. The electronic payment device of claim 33, wherein saidfirst terminal is an entrance terminal, wherein said processor isfurther operative to: facilitate interrogation of said electronicpayment device by an exit terminal upon exit of said holder from saidsystem to said initial entry point information, said exit terminalhaving an exit terminal payment module configured according to thepayment system standard and an exit terminal electronic merchandisemodule configured according to the electronic merchandise infrastructureand coupled to said exit terminal payment module to permit transfer ofnon-payment e-merchandise related information from said exit terminalelectronic merchandise module to said exit terminal payment module; andfacilitate at least one of: providing a ticket to the holder; andcharging a fee to the holder, via said exit terminal payment module,based upon said initial entry point information and a location of saidexit terminal.
 35. A computer-implemented method for integrated paymentand electronic merchandise transfer via a payment infrastructure, havinga payment infrastructure standard, in association with an electronicmerchandise infrastructure, comprising the steps of: facilitatinginterrogation of an electronic device by a first terminal to obtain anaccount number associated with said electronic device, said electronicdevice being configured according to the payment infrastructure standardto support a transaction flow according to the payment infrastructurestandard, said first terminal having a first terminal payment moduleconfigured according to the payment infrastructure standard and a firstterminal electronic merchandise module configured according to theelectronic merchandise infrastructure and coupled to said first terminalpayment module to permit transfer of non-payment e-merchandise relatedinformation from said first terminal electronic merchandise module tosaid first terminal payment module, said interrogation of saidelectronic device being performed by said first terminal payment module;facilitating generation of said non-payment e-merchandise relatedinformation by said first terminal electronic merchandise module; andfacilitating transfer of said non-payment e-merchandise relatedinformation from said first terminal electronic merchandise module tosaid electronic device via said first terminal payment module, within atransaction between said electronic device and said first terminalpayment module that is conducted in accordance with said account numberand the payment infrastructure standard, said non-payment e-merchandiserelated information being stored on said electronic device in accordancewith said payment infrastructure standard.
 36. A terminal for integratedpayment and electronic merchandise transfer via a paymentinfrastructure, having a payment infrastructure standard, in associationwith an electronic merchandise infrastructure and in conjunction with anelectronic device configured according to the payment infrastructurestandard to support a transaction flow according to the paymentinfrastructure standard, said terminal comprising: a payment moduleconfigured according to the payment infrastructure standard andconfigured to interrogate the electronic device to obtain an accountnumber associated with said electronic device; and an electronicmerchandise module configured according to the electronic merchandiseinfrastructure and coupled to said payment module to permit transfer ofnon-payment e-merchandise related information from said electronicmerchandise module to said payment module, said electronic merchandisemodule being configured to facilitate processing of e-merchandiserelated information; wherein said payment module is further configuredto facilitate transfer of said non-payment e-merchandise relatedinformation from said electronic merchandise module to the electronicdevice via said payment module, in a transaction conducted in accordingwith said account device and the payment infrastructure standard, saidnon-payment e-merchandise related information being stored on theelectronic device in accordance with said payment infrastructurestandard.
 37. A computer program product comprising a computer usablemedium including computer usable program code for integrated payment andelectronic merchandise transfer via a payment infrastructure, having apayment infrastructure standard, in association with an electronicmerchandise infrastructure, said computer program product including:computer usable program code for facilitating interrogation of anelectronic device by a first terminal to obtain an accounter numberassociated with said electronic device, said electronic device beingconfigured according to the payment infrastructure standard to support atransaction flow according to the payment infrastructure standard, saidfirst terminal having a first terminal payment module configuredaccording to the payment infrastructure standard and a first terminalelectronic merchandise module configured according to the electronicmerchandise infrastructure and coupled to said first terminal paymentmodule to permit transfer of non-payment e-merchandise relatedinformation from said first terminal electronic merchandise module tosaid fist terminal payment module, said interrogation of said electronicdevice being performed by said first terminal payment module; computerusable program code for facilitating generation of said non-paymente-merchandise related information by said first terminal electronicmerchandise module; and computer usable program code for facilitatingtransfer of said non-payment e-merchandise related information from saidfirst terminal electronic merchandise module to said electronic devicevia said first terminal payment module, within a transaction betweensaid electronic device and said first terminal payment module that isconducted in accordance with said account number and the paymentinfrastructure standard, said non-payment e-merchandise relatedinformation being stored on said electronic device in accordance withsaid payment infrastructure standard.
 38. An electronic device forfacilitating integrated payment and electronic merchandise transfer viaa payment infrastructure, having a payment infrastructure standard, inassociation with an electronic merchandise infrastructure, saidelectronic device being configured according to the paymentinfrastructure standard, said electronic device comprising: a memory;and at least one processor coupled to said memory, said processor beingoperative to: facilitate interrogation of said electronic device by afirst terminal to obtain an account number associated with saidelectronic payment device, said first terminal having a first terminalpayment module configured according to the payment infrastructurestandard and a first terminal electronic merchandise module configuredaccording to the electronic merchandise infrastructure and coupled tosaid first terminal payment module to permit transfer of non-paymente-merchandise related information from said first terminal electronicmerchandise module to said first terminal payment module, saidinterrogation of said electronic device being performed by said firstterminal payment module; facilitate generation of said non-paymente-merchandise related information by said first terminal electronicmerchandise module; and facilitate transfer of said non-paymente-merchandise related information from said first terminal electronicmerchandise module to said electronic device via said first terminalpayment module that is conducted in accordance with said account numberand the payment infrastructure standard, said non-payment e-merchandiserelated information being stored on said electronic payment device inaccordance with said payment infrastructure standard.